The present invention relates to data networking, and more particularly, in certain implementations, to systems and methods for improving synchronization between the forwarding and control planes.
MPLS (Multi-Protocol Label Switching) Traffic Engineering has been developed to meet data networking requirements such as guaranteed available bandwidth. MPLS Traffic Engineering exploits modem label switching techniques to build guaranteed bandwidth end-to-end tunnels through an IP/MPLS network of label switched routers (LSRs). These tunnels are a type of label switched path (LSP) and thus are generally referred to as MPLS Traffic Engineering LSPs.
Like with all IP systems, it is useful to divide MPLS Traffic Engineering network functionality into two entities, the “forwarding plane” (also referred to as the “data plane”) and the “control plane.” On each router the forwarding plane takes the received packet, looks at its destination address and/or label, consults a table, and sends the packet in a direction and manner specified by the table. This table is referred to as a forwarding table. The term “control plane” refers to the entities and processes by which the forwarding tables are populated with their contents.
For MPLS Traffic Engineering the control plane is concerned with, among other things, the placement and signaling of the Traffic Engineering tunnels. Traffic Engineering tunnels are signaled using extensions to the well-known RSVP protocol. After tunnels are signaled and the path established, the forwarding tables along that path from the ingress to the egress should support the operation of the new tunnel. When everything is working correctly, data having a forwarding equivalence class (FEC) assigned to a particular tunnel will arrive at the head-end and be forwarded from node to node along the tunnel path due to the previously established contents of the corresponding forwarding tables.
However, it is possible that the forwarding plane may fail at some point between the head-end and tail-end of the Traffic Engineering LSP without the control plane being affected. For example, the contents of one of the forwarding tables may be corrupted and no control plane entity may be aware of this corruption. The result of this situation is that data belonging to the tunnel is “black holed” without any attempt to reroute the LSP since the Traffic Engineering LSP is considered to be operational from a control plane perspective. The situation poses a problem in that reliability and quality of service guarantees will not be met.
To protect against node and link failures along MPLS Traffic Engineering LSPs, so-called Fast Reroute techniques have been developed. When a failure occurs, traffic is very quickly rerouted onto a preconfigured backup tunnel by the node immediately upstream from the failure. These backup tunnels can however suffer from the same mis-synchronization between the forwarding and control planes discussed with reference to the primary Traffic Engineering tunnels. This is especially problematic since it is the backup tunnels which are to provide protection in the event of failure and a breakdown in the forwarding plane may not be noticed in advance of a failure.
Prior to the failure, the immediately preceding node (also referred to as a point of local repair or PLR) may think that the backup tunnel is operational based on its understanding that the control plane is operational. This PLR would thus report to the protected Traffic Engineering head-end that the Traffic Engineering tunnel is in fact protected at that PLR. Thus when a link or node fails, traffic is rerouted onto a backup tunnel even though its forwarding plane is corrupted, rendering the desired local protection ineffective.
Systems and methods are needed for assuring consistency between the forwarding and control planes for LSPs such as, e.g., MPLS Traffic Engineering tunnels and MPLS Fast Reroute tunnels.